Gui-based wallet program for online transactions

ABSTRACT

Provided is a method and a GUI-based software application that acts as a wallet with network interconnectivity for enabling a user to securely and seamlessly conduct transactions with his or her online financial transaction program by means of a computer or a wireless handheld device without having to depend on an Internet browser.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. application Ser.No. 12/237,060, which was filed on Sep. 24, 2008, the entire disclosureof which is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to online, Internet-based financialtransaction programs and commercial systems and more particularly toconducting online financial transactions with an Internet browserindependent software application.

BACKGROUND OF THE INVENTION

With the advent of the Internet and online electronic commerce(e-commerce), financial transaction programs that allow users toseamlessly purchase products, transfer funds and conduct transactionsover an Internet connection have been in high demand.

Traditional methods of executing financial transactions have beenlimited to a user providing his or her credit card, debit card, orchecking account number on a commercial website, or using checks, moneyorders and other forms of paper-based payments. However, these means ofexecuting financial transactions are often cumbersome, slow, andinconvenient, requiring a user to remember a multitude of accountnumbers, login data and passwords. This often results in significanttime delays for payment processing. Furthermore, security and fraudconcerns are prevalent. For instance, a user is often reluctant toprovide sensitive credit card or debit card information over an Internetconnection, regardless of how “secure” an Internet connection claims tobe.

Recent financial transaction programs have emerged as a means for a userto pay for purchases, transfer money, receive money (if the user is amerchant), store shipping addresses, and set up multiple financialaccounts (e.g. checking or savings, credit card, debit card) all withone single login and password. Security and fraud concerns are alsomitigated by means of online financial security precautions, encryptionmethods, and anti-phising programs that are inherent in online,Internet-based financial transaction systems.

However, many of these financial transaction programs are limited inthat users are dependent on an Internet browser in order to browse to amain website, enter their username and password data and access theiraccount information in order to execute financial transactions such aspaying for purchases, transferring money or checking account balances.

Users are limited in that they are dependent on a computer with Internetaccess and an Internet browser, or a wireless handheld device (e.g. cellphone, BlackBerry, PDA) with an Internet browser application installed.Problems arise if the Internet browser is broken. In that case, the userhas no other means of accessing his or her online financial transactionprogram website. Furthermore, the level of user convenience for a givenInternet browsing experience is limited to the specifications of theInternet browser. In other words, the user is stuck with thehard-to-locate buttons, keys or pull-down menus of a selected Internetbrowser, when the ideal alternative is a user-friendly Graphic UserInterface (GUI) program with intuitive aesthetics and keys/buttonsplaced in regions optimal for user convenience.

Therefore, there is need for a method or software application with auser-friendly GUI setup that enables a user to access their onlinefinancial transaction program account without having to depend on anInternet browser. One such browser-independent solution is the use of asoftware application known as a “Widget”, previously known as“Konfabulator”. Widgets are basically software applications that use aJavaScript runtime environment coupled with an XML interpreter readingXML code to run miniature browser-independent GUI applications. Widgetsalso usually feature a flexible Application Programming Interface (API)for users and programmers to make their own Widgets. Typical Widgetsinclude: weather forecast monitors, temperature or climate indicators,digital clocks, day planners, calendars, stock-tickers, sports gamescoreboards, calculators and currency converters.

However, the one common feature shared by all Widgets is that they areall “passive” monitors, displayers or calculators of information. Forinstance, you only use a Widget to observe the weather, tell the time,convert currency rates, or be informed about the present status of astock or the current score of a sports game. No Widget allows for directinteraction with the external world. For instance, a user cannot use aWidget to conduct financial transactions that have an actual impact onhis or her bank account, which belongs in the physical external world.In other words, a user cannot use a Widget to transfer money fromhis/her bank account, withdraw funds, pay for bills, or perform otherfinancial transactions that have an impact on the world outside of theuser's computer.

Therefore, there is a need in the art for an Internet browserindependent software application similar to Widget-based technology butwhich integrates a network-interconnectivity aspect and which alsoutilizes a user-friendly GUI configuration in order to allow a user toseamlessly and securely conduct financial transactions online with acomputer or wireless handheld device without having to depend on anInternet browser.

SUMMARY OF THE INVENTION

Provided is a method and a GUI-based software application that acts as awallet (“GUI Wallet”) with network interconnectivity for enabling a userto securely and seamlessly conduct transactions with his or her onlinefinancial transaction program by means of a computer or a wirelesshandheld device without having to depend on an Internet browser.

First, the user opens the GUI Wallet and then inputs login informationsuch as a username and a password. Then, a communication engine on thewidget communicates the login information to the communication engine onthe server of an online financial transaction program to see if thelogin information is valid by looking up relevant login information froma database If the login information is valid, then the server pulls upthe user's relevant financial information. Then, the user is presentedwith a plurality of options in the form of buttons in a GUI Wallet.

On a first tab of the GUI Wallet, the user is presented with a pluralityof buttons representing different funding sources (Cash/Checks, Visa,Debit Card and Reward Points) and the user's shipping address and otherID data. The user may drag-and-drop any of these buttons into the blankfields of a merchant's website, and the Wallet program then populatesthe fields with the relevant information (credit card number, shippingaddress, etc.).

On a second tab of the GUI Wallet, the user is presented with aplurality of buttons representing different types of transactions thatcan be performed with an online financial transaction program. Thesebuttons may comprise transferring money, accepting payments ortransfers, checking balances of accounts, paying for bills andconverting currencies. Since the user has already logged in, all therelevant user ID and financial information is stored and ready for use.This enables a convenient means of performing financial transactionswithout having to re-enter login information and without having to relyon an Internet browser.

The GUI Wallet uses a communication engine to communicate with anothercommunication engine located on the server of the online financialtransaction program. The GUI Wallet sends encrypted data to the server'scommunication engine, which decrypts it. Then, the decrypted data issent to an integration engine of the server, which interfaces with aplurality of databases to perform validation, complete transactions andcheck security. The databases store information such as login ID data,user financial data, blacklists of unsafe websites, reward point totalsand transaction histories. Data sent back from the server to the GUIWallet is also encrypted and then decrypted when received by the GUIWallet.

Merchant sites can also be checked for security. If the site is amerchant site that is known for engaging in phishing or fraud, then theGUI Wallet will alert the user. A blacklist of unsafe sites is stored inone of the databases associated with the server of the online financialtransaction program.

Further limitations and disadvantages of conventional and traditionalapproaches will become apparent to one of skill in the art, throughcomparison of such systems with the present invention as set forth inthe remainder of the present application with reference to the drawings.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a diagram of a GUI Wallet with a first plurality of buttonsaccording to an embodiment of the invention.

FIG. 2 is a diagram showing using the GUI Wallet to drag-and-dropbuttons into empty shipping address or ID fields of a merchant websiteaccording to another embodiment of the invention.

FIG. 3 is a diagram showing using the GUI Wallet to drag-and-dropbuttons into empty payment method fields of a merchant website accordingto another embodiment of the invention.

FIG. 4 is a diagram showing the connection between the communicationengine of the GUI Wallet and the communication engine of a serverassociated with an online financial transaction program according toanother embodiment of the invention.

FIG. 5 is a diagram of a GUI Wallet with a second tab having a secondplurality of buttons according to another embodiment of the invention.

FIG. 6 is a flowchart showing the steps a user takes in using a GUIWallet to conduct transactions according to another embodiment of theinvention.

FIG. 7 is a flowchart showing the steps of how the communication engineof the GUI Wallet and the communication engine of the server send andreceive data, according to another embodiment of the invention.

To allow cross-referencing among the figures, like elements in thefigures are provided like reference numerals.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled inthe art to make and use the invention, and is provided in the context ofparticular applications of the invention. Various modifications to thedisclosed embodiments will be apparent to those skilled in the art andthe general principles defined herein may be applied to otherembodiments and applications without departing from the spirit and scopeof the invention.

According to embodiments of the invention, provided is a method and aGUI-based software “Wallet” application or a “GUI Wallet” with networkinterconnectivity for enabling a user to securely and seamlessly conducttransactions with his or her online financial transaction program bymeans of a computer or a wireless handheld device without having todepend on an Internet browser.

FIG. 1 is a diagram of a GUI Wallet with a first plurality of buttons onone or more tabs according to an embodiment of the invention. The firsttab 100 of the GUI Wallet has a plurality of funding source buttons 105,110, 115, 125, an ID button 120 and an alert button 130. Internal to theGUI Wallet software application is the communication engine W 135 of theGUI Wallet, which may be shown on the GUI interface of the GUI Walletwith some sort of GUI indicator, but is shown here in FIG. 1 as ageneric icon. The plurality of funding source buttons can include, forexample, a cash/check/money-order payment button 105 (“Cash”), a Visa orcredit card payment button 110 (“Visa”), a debit card payment button 115(“DbC”), and a reward point payment button 125 (“RwPt”), as shown inFIG. 1. However, the plurality of funding payment buttons is not limitedto the aforementioned list, and the above list is not exhaustive in anyway. The cash/check/money-order payment button 105 is tied to softwarein the GUI Wallet that stores the information about the payment orfunding source, such as a user's check number, money order number, orthe routing number, account number and name of the account holder of achecking account. The Visa or credit card payment button 110 is tied tosoftware in the GUI Wallet that stores a user's credit card informationsuch as credit card type, credit card number, name of cardholder,expiration date of card, and card security code. The debit card paymentbutton 115 is tied to software in the GUI Wallet that stores a user'sdebit card information, which should be identical to the credit cardinformation described above. Finally, the reward point payment button125 is tied to software in the GUI Wallet that stores promotional codenumbers, gift card or gift certificate numbers, reward point codes orother types of currency used in reward point systems. All the above datahas already been entered by the user before. The drag-and-dropfunctionality of the funding source buttons will be further detailed inthe description of FIG. 3.

The ID button 120 as shown in FIG. 1 stores ID information associatedwith the user. In other embodiments, a plurality of different ID buttonscan be displayed and store different types of ID information associatedwith the user. ID information associated with the user may include, butis not limited to: the user's name (including any titles, departmentdesignators, suffixes, prefixes), the shipping address of the user, thebilling address of the user, contact phone numbers of the user, andemail addresses of the user. The ID button 120 is tied to software inthe GUI Wallet that stores this ID information of the user, which hasalready been entered by the user previously. The drag-and-dropfunctionality of the ID source button 120 will be further detailed inthe description of FIG. 2.

The alert button 130 alerts the user on a single issue as shown inFIG. 1. In other embodiments, a plurality of different alert buttons canbe shown and alert the user on different issues. The list of issues thata user can be alerted on include, but is not limited to: whether amerchant site is “unsafe” or has a previous history of phising or fraud,whether the communication link established between the GUI Wallet and agiven merchant site is secure, whether the user's ID information iscorrect and matches the user's records, whether a given transaction hasbeen completed or has been successful, or whether a given transaction isnot successful. An alert button 130 can also trigger pop-ups or messagewindows alerting the user of the aforementioned issues. The alert button130 is tied to software of the GUI Wallet that alerts the user on theaforementioned list of issues.

The communication engine W 135 is the communication engine of the GUIWallet, hence there is a “W” at the end of its name, to denote “Wallet”.The communication engine W 135 communicates with a communication engineS 415 (“S” to denote “Server”), which is further described in FIG. 4.Even though the communication engine W 135 cannot be usually seen on theactual GUI Wallet and it is optional for the GUI Wallet to have an icondenoting the communication engine W 135, a GUI bar, light or box can bemade to indicate to the user that the GUI Wallet is in the process ofcommunicating with a server 410 (in FIG. 4) of the online financialtransaction program by means of the communication engine W 135. This isalmost like a flashing green “status indicator” light frequently seen onprograms or devices that indicate that the program or device is engagingin a current communication with something else or is currently in a“busy” mode. The functionality of the communication engine W 135 and itsinteraction with the communication engine S 415 of the server 410 of theonline financial transaction program will be further detailed in thedescription of FIG. 4.

FIG. 2 is a diagram showing using the GUI Wallet to drag-and-dropbuttons into empty shipping address or ID fields of a merchant websiteaccording to one embodiment of the invention. A user can drag the IDbutton 120 from the first tab 100 of the GUI Wallet and drop it into aUser ID Page 210 of a merchant website. The User ID Page 210 has aplurality of ID fields 215 (e.g. as shown in FIG. 2: Full Name, AddressLine 1, Address Line 2, City, State/Province/Region, ZIP/Postal Code,Country, Phone Number, and Email). However, the plurality of ID fields215 is not limited to the ID fields shown in FIG. 2 nor are the IDfields shown in FIG. 2 in any way exhaustive. Once the user hasdragged-and-dropped the ID button 120 from the first tab 100 of the GUIWallet to the User ID Page 210, the plurality of ID fields 215 arepopulated with the appropriate data. If the user has already entered IDinformation previously, dragging-and-dropping the ID button 120 from thefirst tab 100 of the GUI Wallet to the User ID Page 210 of the merchantwebsite will result in a pre-entered user ID data 220 showing up on theUser ID Page 210. After the ID information has been entered, the usercan then confirm shipping to this address. The user can repeat a similarprocess for entering a billing address or other IDs if multiple IDbuttons are used. The drag-and-drop functionality of the GUI Wallet isrobust, simple and convenient, because it allows a user to simplydrag-and-drop ID information from a portable GUI Wallet into a merchantwebsite without having to remember a multitude of ID data (accountnumbers) and open up a separate Internet browser.

FIG. 3 is a diagram showing using the GUI Wallet to drag-and-dropbuttons into empty payment method fields of a merchant website accordingto another embodiment of the invention. The first tab 100 of the GUIWallet with the plurality of buttons has a plurality of funding sourcebuttons, which include, as shown in FIG. 1, a cash/check/money-orderpayment button 105, a visa or credit card payment button 110, a debitcard payment button 115, and a reward point payment button 125. A usercan drag any of the aforementioned funding source buttons from the firsttab 100 of the GUI Wallet and drop it into a Payment Method Page 310 ofa merchant website. The Payment Method page 310 has a plurality of entryfields, including, as shown in FIG. 3, credit card or debit card entryfields 315, checking account entry fields 320, check or money orderentry field 325, and reward point entry field 330. However, theplurality of entry fields is not limited to the entry fields as shown inFIG. 3 nor are the entry fields shown in FIG. 3 in any way exhaustive.Also, as described above for FIG. 1, the plurality of funding sourcebuttons are not limited to the funding source buttons shown in FIG. 1and are the list of funding source buttons in FIG. 1 are not in any wayexhaustive.

Once the user has dragged-and-dropped any of the plurality of fundingsource buttons from the first tab 100 of the GUI Wallet to the PaymentMethod Page 310, the respective entry field is populated with theappropriate data. For instance, if the user drags-and-drops thecash/check/money-order payment button 105 from the GUI Wallet to achecking account entry field 320 or a check or money order entry field325, those respective fields will be populated with the appropriate data(e.g. for the checking account entry field 320, the “Routing Number”,“Account Number” and “Name of Account Holder” would be filled in withthe user's data, and for the check or money order number, the fieldwould be filled in with the user's data). Also, if the userdrags-and-drops the Visa or credit card payment button 110 or the debitcard payment button 115 from the GUI Wallet to a credit card or debitcard entry field 315, then the relevant fields would be populated withthe appropriate data (e.g. the “Card Type”, “Credit Card Number”, “Nameof Cardholder”, “Exp. Date of Card” and “CSC (Card Security Code)”).Finally, if the user drags-and-drops the reward point payment button 125from the GUI Wallet to a reward point entry field 330, the field wouldbe filled in with the user's data, e.g. a money order number or checknumber or other identifier. The sub-fields of the above mentioned entryfields (e.g. the “Routing Number”, “Account Number” and “Name of AccountHolder” are all sub-fields of the checking account entry field 320) arenot limited to the sub-fields shown in FIG. 3, and can comprise other ordifferent sub-fields, as appropriate. After the relevant paymentinformation has been entered, the user can then confirm a selectedpayment method. The drag-and-drop functionality of the GUI Wallet issimple, robust and convenient, because it allows a user to simplydrag-and-drop payment method information from a portable GUI Wallet intoa merchant website without having to remember a multitude of ID data(account numbers) and open up a separate Internet browser.

FIG. 4 is a diagram showing the connection between the communicationengine of the GUI Wallet and the communication engine of a serverassociated with an online financial transaction program according toanother embodiment of the invention. The communication engine W 135 ofthe GUI Wallet comprising the first tab 100 shown in FIG. 1 and a secondtab 500 shown in FIG. 5 is coupled to an Internet connection 405 to thecommunication engine S 415 of a server 410 of an online financialtransaction program through a bi-directional communicational link 402.The server 410 of the online financial transaction program includes thecommunication engine S 415, an integration engine 420, and a pluralityof databases, for example a user ID database 425, a financial datadatabase 430 and an unsafe website blacklist database 435, as shown inFIG. 4.

However, the plurality of databases of the server 410 is not limited tothe databases shown in FIG. 4, nor are the databases in FIG. 4exhaustive in any way. The databases shown in FIG. 4 are provided forexemplary purposes only. For instance, additional databases couldinclude a database that stores reward points, a database that stores thetransaction history of the user, or a database that stores a list of thestores that the user has shopped at before.

Whenever a user conducts an action with the GUI Wallet (e.g.dragging-and-dropping a button into a page of a merchant website asshown above in FIG. 2 or FIG. 3, or conducting a financial transactionas further detailed in the description of FIG. 5), the communicationengine W 135, the communication engine S 415, the integration engine420, the plurality of databases (shown in FIGS. 4 as 425, 430 and 435)and the server 410 initiate a procedure for sending and receiving data.This procedure is further detailed in the description of the flowchartin FIG. 7. In general, encrypted data is sent from the communicationengine W 135 over the bidirectional communication link 402 to theInternet connection 405 and then to the communication engine S 415,where the data is decrypted. Example data encryption methods comprisesecure 128-bit encryption or 64-bit encryption methods or Secure SocketsLayer (SSL) encryption methods. After the data is received and decryptedby the communication engine S 415, it is sent to the integration engine420. The integration engine 420 works with the received data and theplurality of databases—here, shown as the user ID database 425, thefinancial data database 430 and unsafe website blacklist database 435—inorder to properly execute transactions with the online financialtransaction program, validate the authenticity of IDs, performerror-checking tasks and execute security checks. Specifically, theintegration engine 420 is a business logic interface (any logic oralgorithm that handles the information exchange between a database andother software components) that takes the information received by thecommunication engine S 415 and looks up, verifies and uses data from theplurality of databases in order to effectively conduct transactions.Data coming from the server 410 of the online financial transactionprogram is sent back to the GUI Wallet in the same manner as describedabove. Namely, data is first encrypted by the communication engine S 415and then sent over the bidirectional communication link 402 over theInternet connection 405 to the communication engine W 135, where it isdecrypted and then used.

Examples of using the GUI Wallet will be provided in order to furtherunderstanding of the plurality of databases in the server 410.

For instance, if the user were to drag-and-drop the f ID button 120 intoa User ID Page 210 of a merchant website as described above for FIG. 2,the communication engine W 135 would then communicate this instruction,in encrypted form, over the bidirectional communication link 402 and theInternet connection 405 to the communication engine S 415. Thecommunication engine S 415 would then decrypt the data instruction andsend it to the integration engine 420. The integration engine 420 wouldthen locate the proper ID information from the user ID database 425 andthen use its logic to place the relevant ID information in the pluralityof ID fields 215, as shown in FIG. 2.

A similar process exists if the user were to drag-and-drop any of theplurality of funding source buttons into a Payment Method Page 310 of amerchant website as described above for FIG. 3. The communication engineW 135 would communicate this instruction over the bidirectionalcommunication link 402 and the Internet connection 405 to thecommunication engine S 415. The communication engine S 415 would thendecrypt the data instruction and send it to the integration engine 420.The integration engine 420 would then locate the proper ID informationfrom the financial data database 430 and then use its logic to place therelevant financial data in any of the plurality of entry fields (e.g.315, 320, 325 or 330) as shown in FIG. 3.

The above described process also enables the alert button 130 of thefirst tab 100 of the GUI Wallet to issue an alarm, as described abovefor FIG. 1. Any time a merchant website is browsed, the server 410 ofthe online financial transaction program is engaged and the integrationengine 420 can readily perform lookups with the plurality of databases.If the user is attempting to make a transaction on a potentially unsafewebsite, the integration engine 420 checks the potentially unsafewebsite against the websites listed in the unsafe website blacklistdatabase 435. If there is a match, then the communication engine S 415sends an encrypted message about this unsafe website over the Internetconnection 405 and the bidirectional communication link 402 to thecommunication engine W 135, where it is then decrypted and then sent tothe alert button 130 for alerting the user, such as lighting-up a GUIfeature or popping up a separate message window.

The above described process also enables message windows to pop up fromeither the first tab 100 or the second tab 500 of the GUI Wallet toinform the user if a transaction was successful (e.g. a money transferor currency conversion) or a message window informing the user of aspecific piece of information (e.g. a specific balance amount afterperforming a balance inquiry), as will be further detailed in thedescription of FIG. 5. Any time a user decides to conduct a financialtransaction with the second tab 500 of the GUI Wallet, the server 410 ofthe online financial transaction program is engaged and the integrationengine 420 can readily perform lookups with the plurality of databases.Once the user has completed a transaction, successfully or not, orperformed a balance inquiry, the communication engine S 415 sends anencrypted message about the status of the transaction (successful orunsuccessful) or the specific balance amount inquired about over theInternet connection 405 and the bidirectional communication link 402 tothe communication engine W 135, where it is then decrypted and thendisplayed as a message window in the GUI Wallet. For instance, a messagewindow could pop up stating that the transaction (e.g. money transfer orcurrency conversion) was successful or unsuccessful, or a message windowcould pop up describing to the user the specific balance of an accountthe user performed a balance inquiry on. The details of this processwill also be described in the descriptions of FIG. 5 and FIG. 7.

FIG. 5 is a diagram of a GUI Wallet with a second tab having a secondplurality of buttons according to another embodiment of the invention.The second tab 500 of the GUI Wallet is shown behind the first tab 100of the GUI Wallet, but the second tab 500 is not limited to thisposition and can be located anywhere with respect to the first tab 100.Furthermore, the number of tabs of the GUI Wallet is not limited tomerely two, and the first tab 100 and second tab 500 are provided onlyfor illustrative purposes. Additional tabs may be added as necessary oras a software engineer sees fit. The second tab 500 includes a pluralityof transaction buttons and like FIG. 1, a GUI representation of thecommunication engine W 135, which is internal to the GUI Wallet softwareapplication but can be represented by any GUI indicator, but is shown inFIG. 5 as a generic icon.

The second tab 500 of the GUI Wallet comprises a plurality oftransaction buttons which can include, for example, a balance checkbutton 505 (“Bal.”), a transfer money button 510 (“Send”), and acurrency conversion button 515 (“Con.”), as shown in FIG. 5. However,the plurality of transaction buttons is not limited to theaforementioned list, and the above list is not exhaustive in any way.For example, other transaction buttons can include a button that acceptspayments or money transfers from another party, a button that can paybills or set-up bill payments, and a button that can perform anyfinancial transaction that is performed with an online financialtransaction program via an Internet browser.

The balance check button 505 is tied to software in the GUI Wallet thathas the user's login information already entered, and that is able toretrieve the balance of a given account belonging to the user that isregistered with the user's online financial transaction program. Forinstance, if the user were to select the balance check button 505, apop-up window with a field querying the user for an account number orother account identifier would appear. After the user enters the accountnumber or other account identifier, the GUI Wallet retrieves and returnsto the user the balance of the particular account associated with theprovided account number or identifier, usually by means of anothermessage window. The balance check button 505 also works with thecommunication engine method described above for FIG. 4 and looks up thebalance of a particular user account in the plurality of databases, forexample the financial data database 430 shown in FIG. 4, and sends thisdata back to the GUI Wallet from the server in order to have the GUIWallet display to the user the proper balance of a selected account, forinstance in a separate message window.

The transfer money button 510 is tied to software in the GUI Wallet thathas the user's login information already entered, and that is able toaccess the financial data of a user's account and actually transfermoney from a user's account to another account or to pay for purchases.For instance, if the user were to select the transfer money button 510,a pop-up window with a field querying the user for a transferee ordestination account number and a transfer amount would appear. After theuser enters the transferee/destination number and the transfer amount,the GUI Wallet executes the money transfer and then informs the userabout whether the money transfer was successful or not, usually by meansof another message window or by using the alert window 130 of the firsttab 100 of the GUI Wallet. The transfer money button 510 also works withthe communication engine method described above for FIG. 4 and is ableto work with the plurality of databases in the server 410 and canexecute financial transactions (e.g. a money transfer) over the server410 just as if the user were performing transactions through his or heronline financial transaction program website. A data message describingwhether the money transfer was successful or not is also sent from theserver back to the GUI Wallet in order to have the GUI Wallet display tothe user whether or not the money transfer was successful in a separatemessage window.

The currency conversion button 515 is tied to software in the GUI Walletthat has the user's login information already entered, and that is ableto access the financial data of a user's account and actually convertfunds from a user's account from one type of currency to another type ofcurrency. For instance, if the user were to select the currencyconversion button 515, a pop-up window with a field querying the userfor a beginning currency type, a beginning currency amount, and an endcurrency type would appear. After the user enters the beginning currencytype, a beginning currency amount, and an end currency type, the GUIWallet executes the currency conversion and then informs the user aboutwhether the currency conversion was successful or not, usually by meansof another message window or by using the alert button 130 of the firsttab 100 of the GUI Wallet. The currency conversion button 515 also workswith the communication engine method described above for FIG. 4 and isable to work with the plurality of databases and can execute financialtransactions (e.g. currency conversion) over the server 410 just as ifthe user were performing financial transactions through his or heronline financial transaction program website. A data message describingwhether the currency conversion was successful or not is also sent fromthe server back to the GUI Wallet in order to have the GUI Walletdisplay to the user whether or not the currency conversion wassuccessful in a separate message window.

Again, it is to be reiterated that the plurality of transaction buttonsis not limited to the above three described buttons and can comprisebuttons that allow a user to perform any other financial transactionthat the user would have been able to perform on the user's financialtransaction program website with an Internet browser. For instance,other transaction buttons can include a button that accepts payments ormoney transfers from another party (which may be more applicable if theuser was a merchant), and a button that can pay bills or set-up billpayments (on a periodic or non-periodic basis). The use of the pluralityof transaction buttons on the second tab 500 of the GUI Wallet isrobust, simple and convenient because it allows a user to conductfinancial transactions with his or her online financial transactionprogram seamlessly and securely, independent of an Internet browser.

FIG. 6 is a flowchart showing the steps a user takes in using a GUIWallet to conduct transactions according to another embodiment of theinvention. Method 600 is the process in which the user drags-and-drops afunding source or ID button or pushes a transaction button of the GUIWallet in order to conduct a transaction with the GUI Wallet. In step605, the user starts the process and opens up the GUI Walletapplication. In step 610, the user supplies relevant log-in data tolog-in to the server 410 of the online financial transaction program,shown in FIG. 4. This is usually the username and password a user usesto log-in to his or her account on a central online financialtransaction program website. If the user cannot log-in, the user isbrought back to step 605, the start of the process. If the usersuccessfully logs in, then in step 615, the user's status and financialinformation is checked and verified by looking up the data in thefinancial data database 430 of the server 410 of the online financialtransaction program. Then, the GUI Wallet appears on a user's screen,and in step 625, the user is presented with a plurality of buttons, suchas the plurality of funding source buttons as well as the ID and alertbuttons described in FIG. 1 and the plurality of transaction buttonsdescribed in FIG. 5. If the user wishes to use the drag-and-dropfunctionality of the plurality of funding source buttons, then the userwill go to a page of a merchant website in order to make a purchase.Once the user is on the merchant website, the server 410 of the onlinefinancial transaction program is engaged, and the server 410 works withthe integration engine 420 to check, in step 630, if the merchantwebsite the user is browsing belongs to the blacklist of unsafe websitesstored in the unsafe website blacklist database 435.

If the merchant website is unsafe, then in step 620, a warning isdisplayed either in a separate message window or on the alert button 130of the first tab 100 of the GUI Wallet. If the merchant website is safe,then the user can continue to choose one of the plurality of fundingsource buttons to drag-and-drop into a merchant website, or the user canchoose to conduct a financial transaction (e.g. transferring money,converting currencies, checking balances) that is independent of amerchant website, in step 635. In step 640, the GUI Wallet and theserver 410 communicate in the process described above for FIG. 4 and themethod that will be detailed in FIG. 7 in order to conduct thetransaction that the user has selected. In step 645, the server 410determines whether or not the transaction was successful. If thetransaction was not successful, a message window is displayed from theGUI Wallet that describes the transaction failure and the reason forfailure in step 655. If, on the other hand, the transaction issuccessful, a message window is displayed from the GUI Wallet thatdescribes the success of the transaction and the reason why thetransaction was a success in step 650. Then, in step 660, the user hasthe choice of returning to step 625 to select another button from theGUI Wallet, or deciding to end method 600. If the user decides to endthe method 600, the user starts all over from step 605 and logs in againin step 610.

FIG. 7 is a flowchart showing the steps of how the communication engineof the GUI Wallet and the communication engine of the server send andreceive data, according to another embodiment of the invention. Method700 is the process in which communication engine W 135 and communicationengine S 415 encrypt, send and receive data to one another, as describedabove for FIG. 4. The method starts in step 705, and in step 710, themethod determines whether the processing starts from the GUI Walletside, or starts from the server side. Basically, the processing startsfrom the GUI Wallet side if the user is using the first tab 100 of theGUI Wallet and plans to drag-and-drop a button from the plurality ofbuttons available (e.g. the plurality of funding source buttons or an IDbutton) into a page of a merchant website. On the other hand, theprocessing starts from the server side if the user decides to use atransaction button from the plurality of transaction buttons on thesecond tab 500 of the GUI Wallet. The processing also starts from theserver side if the user is simply browsing a merchant website and themerchant website is unsafe, thereby triggering the alarm button 130. Ifthe processing starts from the server side, then the method proceeds tostep 735. If the processing starts from the GUI Wallet side, then themethod proceeds to step 715, where the communication engine W 135encrypts a data message instruction, usually by using a secure 64-bit or128-bit encryption method or a SSL encryption method. A data messageinstruction usually comprises the software instructions for having theuser drag-and-drop a button from the first tab 100 of the GUI Walletinto a page of the merchant website.

Then, in step 720, the encrypted data message instruction is sent overthe bidirectional communication link 402 and the Internet connection 405and crosses into the server side to reach step 725. In step 725,communication engine S 415 receives and decrypts the data messageinstruction. The communication engine S 415 then sends the decrypteddata message instruction to the integration engine 420. In step 735, theserver 410 is engaged because the user is browsing a page of themerchant website, and the server 410 is engaged whenever the user isperforming Internet browsing. In step 735, the integration engine 420works with the plurality of databases (shown in FIG. 4 as elements 425,430 and 435 for exemplary purposes only) and the server 410, as well asany incoming data message instructions sent by the communication engineS 415 to perform any functions. These functions can comprise populatingempty fields of a page on a merchant website with user ID data orpayment method data, conducting financial transactions with the onlinefinancial transaction program (e.g. money transfers, currencyconversions, paying for purchases), validating the authenticity of userlogin IDs, performing error-checking tasks and executing security checkson potentially unsafe websites. Then, after step 735, where theintegration engine 420 works with the databases and the server 410 toperform any tasks, the method determines whether a message has to bedisplayed by the GUI Wallet in order to alert the user on the status ofa certain transaction. In the case of a simple drag-and-drop of afunding source or ID button from the first tab 100 of the GUI Wallet,the user does not need to be notified with a message window from the GUIWallet because the user can immediately see the empty fields of amerchant website page being populated with the user's data. In such acase where a message does not need to be displayed to the user, themethod then proceeds to step 745 and goes back to the start, step 705,and then the above mentioned process is repeated.

However, if it is necessary to have a message displayed by the GUIWallet, and a “Yes” is answered to the inquiry posed in step 740, thenthe method proceeds to step 750. In step 750, the method is still on theserver side, therefore communication engine S 415 encrypts a datamessage instruction, usually by using a secure 64-bit or 128-bitencryption method or a SSL encryption method. The data messageinstruction is usually the software instructions for having the userdrag-and-drop a button from the first tab 100 of the GUI Wallet into apage of the merchant website. The data message instruction here usuallycomprises the software instructions for displaying a status message tothe user by using the GUI Wallet to display a separate message window orhaving the alert button 130 light up or animate. This data messageinstruction is being sent to the GUI Wallet side from the server sidebecause it is ultimately the GUI Wallet that will be displaying themessage for the user to view.

In step 755, the encrypted data message is sent by the communicationengine S 415 over the bidirectional communication link 402 and theInternet connection 405 over to the GUI Wallet side, where it isreceived by communication engine W 135 and decrypted in step 760. Then,the GUI Wallet takes the software instruction from the decrypted datamessage instruction and then displays a message in a separate messagewindow from the GUI Wallet or uses the alarm button 130 of the GUIWallet to display the warning or message. After the message isdisplayed, the method proceeds to step 770 and goes back to the start,or step 705.

The message the user will view usually comprises either a successful orunsuccessful completion of a financial transaction (e.g. whether moneywas successfully transferred, or received, or whether currency has beensuccessfully converted), the balance of a certain account the user hasperformed a balance inquiry on, or whether the user has reached anunsafe site and informing the user that he or she is currently browsingan unsafe site.

Even though the GUI Wallet comprises a first tab 100 and a second tab500 and each tab comprises a plurality of different buttons, asdescribed above, the buttons detailed above associated with the firsttab 100 do not necessarily have to be placed on the first tab 100 andthe buttons detailed above associated with the second tab 500 do nothave to be placed on the second tab 500. In other words, the buttons canbe placed anywhere with respect to the GUI Wallet. In addition, the GUIWallet is not limited to just a first tab 100 and a second tab 500 andcan comprise any number of tabs, and the buttons can be placed on any ofthese tabs.

The GUI Wallet can also be customized in any way that a user, aconnected system, control logic or another entity sees fit. In otherwords, buttons on any of the tabs can be moved to other tabs, new tabscan be created, tabs can be removed or modified, existing buttons can beremoved or modified, and new buttons can be added. The customizabilityof the GUI Wallet is intrinsic to the GUI properties of the GUI Walletand is not limited to the above examples. The GUI Wallet can also becustomized to optimize the user experience.

The GUI Wallet and any of the tabs of the GUI Wallet can be written in alanguage comprising Java, XML, C++ or C, and can also be written in alanguage with a flexible and user-customizable API where a user can addon features easily without having to understand the intricacies of aparticular code. The plurality of databases in the server 410 can bewritten in a language comprising SQL, Perl, or another databaselanguage. The communication engine W 135, the communication engine S415, and the integration engine 420 can be written in a languagecomprising C, C++ or Java.

Advantages of the present invention include granting a user the abilityto securely and seamlessly conduct transactions with his or her onlinefinancial transaction program by means of a computer or a wirelesshandheld device without having to depend on an Internet browser. Aconvenient drag-and-drop functionality also enables the user to simplydrag-and-drop pre-stored settings and information into empty fields of apage of a merchant website without having to remember account numbers orother ID data or open up a separate page in another Internet browser.

The above-described embodiments of the present invention are merelymeant to be illustrative and not limiting. It will thus be obvious tothose skilled in the art that various changes and modifications may bemade without departing from this invention in its broader aspects.Therefore, the appended claims encompass all such changes andmodifications as fall within the true spirit and scope of thisinvention.

We claim:
 1. A transaction information provisioning system, comprising:a user device that is configured to render a graphical user interface(GUI) wallet for display on the user device in response to aninteraction with a first electronic transaction system that includes afirst rewards program input, wherein the GUI wallet includes a pluralityof user-selectable rewards program elements that are each associatedwith a different one of a plurality of rewards programs and that areeach selectable by a user to designate a respective one of the pluralityof rewards programs; a communication engine that is located in the userdevice and that is configured to: detect a selection of a first rewardsprogram element from the plurality of user-selectable rewards programelements included on the GUI wallet and, in response, send a firstrewards program information request over a network, wherein the firstrewards program information request is for first rewards programinformation for a first rewards program of the plurality of rewardsprograms; receive an encrypted first rewards program informationresponse through the network; decrypt the encrypted first rewardsprogram information response to retrieve the first rewards programinformation; and automatically provide the first rewards programinformation in the first rewards program input of the first electronictransaction system.
 2. The transaction information provisioning systemof claim 1, further comprising: the user device that is configured torender the GUI wallet for display on the user device in response to aninteraction with a second electronic transaction system that includes asecond rewards program input and that is different than the firstelectronic transaction system; the communication engine that is locatedin the user device and that is configured to: detect a selection of asecond rewards program element from the plurality of user-selectablerewards program elements included on the GUI wallet that is differentfrom the first rewards program element and, in response, send a secondrewards program information request over the network, wherein the secondrewards program information request is for second rewards programinformation for a second rewards program of the plurality of rewardsprograms that is different than the first rewards program; receive anencrypted second rewards program information response through thenetwork; decrypt the encrypted second rewards program informationresponse to retrieve the second rewards program information; andautomatically provide the second rewards program information in thesecond rewards program input of the second electronic transactionsystem.
 3. The transaction information provisioning system of claim 1,wherein the plurality of rewards program information includes rewardspoints, rewards currency, and rewards codes.
 4. The transactioninformation provisioning system of claim 1, further comprising: the userdevice that is configured to render the GUI wallet for display on theuser device in response to an interaction with the first electronictransaction system that includes a first user identification input,wherein the GUI wallet includes a plurality of user-selectable useridentification elements that are each associated with a different one ofa plurality of user contact identifiers and that are each selectable bya user to designate a respective one of the plurality of user contactidentifiers; the communication engine that is located in the user deviceand that is configured to: detect a selection of a first useridentification element from the plurality of user-selectable useridentification elements included on the GUI wallet and, in response,send a first user identification information request over the network,wherein the first user identification information request is for firstuser identification information for a first user contact identifier ofthe plurality of user contact identifiers; receive an encrypted firstuser identification information response through the network; decryptthe encrypted first user identification information response to retrievethe first user identification information; and automatically provide thefirst user identification information in the first user identificationinput of the first electronic transaction system.
 5. The transactioninformation provisioning system of claim 4, further comprising: the userdevice that is configured to render the GUI wallet for display on theuser device in response to an interaction with a second electronictransaction system that includes a second user identification input andthat is different than the first electronic transaction system; thecommunication engine that is located in the user device and that isconfigured to: detect a selection of a second user identificationelement from the plurality of user-selectable user identificationelements included on the GUI wallet that is different from the firstuser identification element and, in response, send a second useridentification information request over the network, wherein the seconduser identification information request is for second useridentification information for a second user contact identifier of theplurality of user contact identifiers that is different than the firstuser contact identifier; receive an encrypted second user identificationinformation response through the network; decrypt the encrypted seconduser identification information response to retrieve the second useridentification information; and automatically provide the second useridentification information in the second user identification input ofthe second electronic transaction system.
 6. The transaction informationprovisioning system of claim 1, further comprising: the user device thatis configured to render the GUI wallet for display on the user device inresponse to an interaction with the first electronic transaction systemthat includes a first transaction information input, wherein the GUIwallet includes a plurality of user-selectable transaction elements thatare each associated with a different one of a plurality of transactiondevices and that are each selectable by a user to designate a respectiveone of the plurality of transaction devices; the communication enginethat is located in the user device and that is configured to: detect aselection of a first transaction element from the plurality ofuser-selectable transaction elements included on the GUI wallet and, inresponse, send a first transaction information request over the network,wherein the first transaction information request is for firsttransaction information for a first transaction device of the pluralityof transaction devices; receive an encrypted first transactioninformation response through the network; decrypt the encrypted firsttransaction information response to retrieve the first transactioninformation; and automatically provide the first transaction informationin the first transaction information input of the first electronictransaction system.
 7. The transaction information provisioning systemof claim 7, further comprising: the user device that is configured torender the GUI wallet for display on the user device in response to aninteraction with a second electronic transaction system that includes asecond transaction information input and that is different than thefirst electronic transaction system; the communication engine that islocated in the user device and that is configured to: detect a selectionof a second transaction element from the plurality of user-selectabletransaction elements included on the GUI wallet that is different fromthe first transaction element and, in response, send a secondtransaction information request over the network, wherein the secondtransaction information request is for second transaction informationfor a second transaction device of the plurality of transaction devicesthat is different than the first transaction device; receive anencrypted second transaction information response through the network;decrypt the encrypted second transaction information response toretrieve the second transaction information; and automatically providethe second transaction information in the second transaction informationinput of the second electronic transaction system.
 8. A method forproviding transaction information, comprising: rendering, by a userdevice for display on a display device that is included on the userdevice, a graphical user interface (GUI) wallet in response to aninteraction with a first electronic transaction system that includes afirst rewards program input, wherein the GUI wallet includes a pluralityof user-selectable rewards program elements that are each associatedwith a different one of a plurality of rewards programs and that areeach selectable by a user to designate a respective one of the pluralityof rewards programs; detecting, by a communication engine that islocated in the user device, a selection of a first rewards programelement from the plurality of user-selectable rewards program elementsincluded on the GUI wallet and, in response, sending a first rewardsprogram information request over a network, wherein the first rewardsprogram information request is for first rewards program information fora first rewards program of the plurality of rewards programs; receiving,by the communication engine, an encrypted first rewards programinformation response through the network; decrypting, by thecommunication engine, the encrypted first rewards program informationresponse to retrieve the first rewards program information; andautomatically providing, by the communication engine, the first rewardsprogram information in the first rewards program input of the firstelectronic transaction system.
 9. The method of claim 8, furthercomprising: rendering, by the user device for display on the displaydevice that is included on the user device, the GUI wallet in responseto an interaction with a second electronic transaction system thatincludes a second rewards program input and that is different than thefirst electronic transaction system; detecting, by the communicationengine that is located in the user device, a selection of a secondrewards program element from the plurality of user-selectable rewardsprogram elements included on the GUI wallet that is different from thefirst rewards program element and, in response, sending a second rewardsprogram information request over the network, wherein the second rewardsprogram information request is for second rewards program informationfor a second rewards program of the plurality of rewards programs thatis different than the first rewards program; receiving, by thecommunication engine, an encrypted second rewards program informationresponse through the network; decrypting, by the communication engine,the encrypted second rewards program information response to retrievethe second rewards program information; and automatically providing, bythe communication engine, the second rewards program information in thesecond rewards program input of the second electronic transactionsystem.
 10. The method of claim 8, wherein the plurality of rewardsprogram information includes rewards points, rewards currency, andrewards codes.
 11. The method of claim 8, further comprising: rendering,by the user device for display on the display device that is included onthe user device, the GUI wallet in response to an interaction with thefirst electronic transaction system that includes a first useridentification input, wherein the GUI wallet includes a plurality ofuser-selectable user identification elements that are each associatedwith a different one of a plurality of user contact identifiers and thatare each selectable by a user to designate a respective one of theplurality of user contact identifiers; detecting, by the communicationengine that is located in the user device, a selection of a first useridentification element from the plurality of user-selectable useridentification elements included on the GUI wallet and, in response,sending a first user identification information request over thenetwork, wherein the first user identification information request isfor first user identification information for a first user contactidentifier of the plurality of user contact identifiers; receiving, bythe communication engine, an encrypted first user identificationinformation response through the network; decrypting, by thecommunication engine, the encrypted first user identificationinformation response to retrieve the first user identificationinformation; and automatically providing, by the communication engine,the first user identification information in the first useridentification input of the first electronic transaction system.
 12. Themethod of claim 11, further comprising: rendering, by the user devicefor display on the display device that is included on the user device,the GUI wallet in response to an interaction with a second electronictransaction system that includes a second user identification input andthat is different than the first electronic transaction system;detecting, by the communication engine that is located in the userdevice, a selection of a second user identification element from theplurality of user-selectable user identification elements included onthe GUI wallet that is different from the first user identificationelement and, in response, sending a second user identificationinformation request over the network, wherein the second useridentification information request is for second user identificationinformation for a second user contact identifier of the plurality ofuser contact identifiers that is different than the first user contactidentifier; receiving, by the communication engine, an encrypted seconduser identification information response through the network;decrypting, by the communication engine, the encrypted useridentification information response to retrieve the second useridentification information; and automatically providing, by thecommunication engine, the second user identification information in thesecond user identification input of the second electronic transactionsystem.
 13. The method of claim 8, further comprising: rendering, by theuser device for display on the display device that is included on theuser device, the GUI wallet in response to an interaction with the firstelectronic transaction system that includes a first transactioninformation input, wherein the GUI wallet includes a plurality ofuser-selectable transaction elements that are each associated with adifferent one of a plurality of transaction devices and that are eachselectable by a user to designate a respective one of the plurality oftransaction devices; detecting, by the communication engine that islocated in the user device, a selection of a first transaction elementfrom the plurality of user-selectable transaction elements included onthe GUI wallet and, in response, sending a first transaction informationrequest over the network, wherein the first transaction informationrequest is for first transaction information for a first transactiondevice of the plurality of transaction devices; receiving, by thecommunication engine, an encrypted first transaction informationresponse through the network; decrypting, by the communication engine,the encrypted first transaction information response to retrieve thefirst transaction information; and automatically providing, by thecommunication engine, the first transaction information in the firsttransaction information input of the first electronic transactionsystem.
 14. The method of claim 13, further comprising: rendering, bythe user device for display on the display device that is included onthe user device, the GUI wallet in response to an interaction with asecond electronic transaction system that includes a second transactioninformation input and that is different than the first electronictransaction system; detecting, by the communication engine that islocated in the user device, a selection of a second transaction elementfrom the plurality of user-selectable transaction elements included onthe GUI wallet that is different from the first transaction element and,in response, sending a second transaction information request over thenetwork, wherein the second transaction information request is forsecond transaction information for a second transaction device of theplurality of transaction devices that is different than the firsttransaction device; receiving, by the communication engine, an encryptedsecond transaction information response through the network; decrypting,by the communication engine, the encrypted transaction informationresponse to retrieve the second transaction information; andautomatically providing, by the communication engine, the secondtransaction information in the second transaction information input onthe second electronic transaction system.
 15. A non-transitory,machine-readable medium comprising a plurality of machine-readableinstructions that, when executed by one or more processors, areconfigured to cause the one or more processors to perform a methodcomprising: rendering a graphical user interface (GUI) wallet on adisplay device in response to an interaction with a first electronictransaction system that includes a first rewards program input, whereinthe GUI wallet includes a plurality of user-selectable rewards programelements that are each associated with a different one of a plurality ofrewards programs and that are each selectable by a user to designate arespective one of the plurality of rewards programs; and providing acommunication engine that: detects a selection of a first rewardsprogram element from the plurality of user-selectable rewards programelements included on the GUI wallet and, in response, sends a firstrewards program information request over a network, wherein the firstrewards program information request is for first rewards programinformation for a first rewards program of the plurality of rewardsprograms; receives an encrypted first rewards program informationresponse through the network; decrypts the encrypted first rewardsprogram information response to retrieve the first rewards programinformation; and automatically provides the first rewards programinformation in the first rewards program input on the first electronictransaction system.
 16. The machine-readable medium of claim 15, whereinthe plurality of machine-readable instructions are configured to causethe one or more processors to perform the method further comprising:rendering the GUI wallet on the display device in response to aninteraction with a second electronic transaction system that includes asecond rewards program input and that is different than the firstelectronic transaction system; and providing the communication enginethat: detects a selection of a second rewards program element from theplurality of user-selectable rewards program elements included on theGUI wallet that is different from the first rewards program element and,in response, sends a second rewards program information request over thenetwork, wherein the second rewards program information request is forsecond rewards program information for a second rewards program of theplurality of rewards programs that is different than the first rewardsprogram; receives an encrypted second rewards program informationresponse through the network; decrypts the encrypted second rewardsprogram information response to retrieve the second rewards programinformation; and automatically provides the second rewards programinformation in the second rewards program input on the second electronictransaction system.
 17. The machine-readable medium of claim 15, whereinthe plurality of machine-readable instructions are configured to causethe one or more processors to perform the method further comprising:rendering the GUI wallet on the display device in response to aninteraction with the first electronic transaction system that includes afirst user identification input, wherein the GUI wallet includes aplurality of user-selectable user identification elements that are eachassociated with a different one of a plurality of user contactidentifiers and that are each selectable by a user to designate arespective one of the plurality of user contact identifiers; andproviding the communication engine that: detects a selection of a firstuser identification element from the plurality of user-selectable useridentification elements included on the GUI wallet and, in response,sends a first user identification information request over the network,wherein the first user identification information request is for firstuser identification information for a first user contact identifier ofthe plurality of user contact identifiers; receives an encrypted firstuser identification information response through the network; decryptsthe encrypted first user identification information response to retrievethe first user identification information; and automatically providesthe first user identification information in the first useridentification input on the first electronic transaction system.
 18. Themachine-readable medium of claim 17, wherein the plurality ofmachine-readable instructions are configured to cause the one or moreprocessors to perform the method further comprising: rendering the GUIwallet on the display device in response to an interaction with a secondelectronic transaction system that includes a second user identificationinput and that is different than the first electronic transactionsystem; and providing the communication engine that: detects a selectionof a second user identification element from the plurality ofuser-selectable user identification elements included on the GUI walletthat is different from the first user identification element and, inresponse, sends a second user identification information request overthe network, wherein the second user identification information requestis for second user identification information for a second user contactidentifier of the plurality of user contact identifiers that isdifferent than the first user contact identifier; receives an encryptedsecond user identification information response through the network;decrypts the encrypted second user identification information responseto retrieve the second user identification information; andautomatically provides the second user identification information in thesecond user identification input on the second electronic transactionsystem.
 19. The machine-readable medium of claim 15, wherein theplurality of machine-readable instructions are configured to cause theone or more processors to perform the method further comprising:rendering the GUI wallet on the display device in response to aninteraction with the first electronic transaction system that includes afirst transaction information input, wherein the GUI wallet includes aplurality of user-selectable transaction elements that are eachassociated with a different one of a plurality of transaction devicesand that are each selectable by a user to designate a respective one ofthe plurality of transaction devices; and providing the communicationengine that: detects a selection of a first transaction element from theplurality of user-selectable transaction elements included on the GUIwallet and, in response, sends a first transaction information requestover the network, wherein the first transaction information request isfor first transaction information for a first transaction device of theplurality of transaction devices; receives an encrypted firsttransaction information response through the network; decrypts theencrypted first transaction information response to retrieve the firsttransaction information; and automatically provides the firsttransaction information in the first transaction information input onthe first electronic transaction system.
 20. The machine-readable mediumof claim 19, wherein the plurality of machine-readable instructions areconfigured to cause the one or more processors to perform the methodfurther comprising: rendering the GUI wallet on the display device inresponse to an interaction with a second electronic transaction systemthat includes a second transaction information input and that isdifferent than the first electronic transaction system; and providingthe communication engine that: detects a selection of a secondtransaction element from the plurality of user-selectable discountelements included on the GUI wallet that is different from the firsttransaction element and, in response, sends a second transactioninformation request over the network, wherein the second transactioninformation request is for second transaction information for a secondtransaction device of the plurality of transaction devices that isdifferent than the first transaction device; receives an encryptedsecond transaction information response through the network; decryptsthe encrypted second transaction information response to retrieve thesecond transaction information; and automatically provides the secondtransaction information in the second transaction information input onthe second electronic transaction system.